From: ibis-interconn-bounce@freelists.org on behalf of Mirmak, Michael [michael.mirmak@intel.com] Sent: Tuesday, September 14, 2010 10:13 AM To: IBIS-Interconnect Subject: [ibis-interconn] IBIS Interconnect Task Group Sept. 8 Minutes and Sept. 15 Agenda ====================================================================== IBIS INTERCONNECT MODELING TASK GROUP MEETING MINUTES AND AGENDA http://www.eda.org/ibis/interconnect_wip/ (note new URL) Mailing list: ibis-interconn@freelists.org ====================================================================== Next Meeting Wednesday, September 15, 2010 9 AM US Pacific Time Telephone Bridge Passcode 916-356-2663 5 182-0833 (for international and alternate US numbers, contact Michael Mirmak) LiveMeeting: https://webjoin.intel.com/?passcode=1820833 Agenda: - Attendees - Call for patents - Opens - MCP Comments Review and live editing ====================================================================== Minutes from September 8: Attendees: ---------- (* denotes present) Agilent - Radek Biernacki, John Moore, Ken Wong Ansoft - Denis Soldo Cadence Design Systems - Terry Jernberg, Brad Griffin, Dennis Nagle* Cisco Systems - Mike LaBonte Green Streak Programs - Lynne Green Hewlett-Packard - Rob Elliott IBM - Greg Edlund ICT-Lanto - Steven Wong* Intel - Michael Mirmak* Mentor Graphics Corp. - Arpad Muranyi*, John Angulo*, Vladimir Dmitriev- Zdorov Micron Technology - Randy Wolff*, Justin Butterfield Sigrity - Sam Chitwood, Raymond Y. Chen, Tao Su, Brad Brim SiSoft - Walter Katz* Teraspeed Consulting Group - Bob Ross* ======================================================================== No patents were declared. During opens, Arpad Muranyi asked whether the current version of the IBIS-ISS draft is 0.5? Michael Mirmak responded that this was true. Bob Ross raised a few new items regarding Touchstone: a) no updates are available on whether Agilent's developer is available to perform Touchstone parser upgrades, including binary support b) Bob suggested moving the recent changes to Touchstone 3.0, not 2.1 (as only two companies have purchased the parser today. This follows from the idea that the binary change is a significant upgrade. In reality, an x.1 version is for fixes rather than major upgrades; the original idea was to keep it an editorial update for potential standardization. Michael suggested bringing this up at the next IBIS Open Forum meeting for discussion. Michael reviewed a list of options for the IBIS-ISS document, including lists of permitted and prohibited commands, strings, keywords and the like. Regarding .TEMP, which was listed as prohibited, Arpad noted that multiple .TEMP statements force multiple sims, similar to .ALTER. Walter Katz and Arpad both agreed that temperature settings should not be applied to R, C, etc. devices in IBIS-ISS (i.e., no DTEMP support should be included). Michael noted that most of the prohibitions were uncontroversial except .DATA/.ENDDATA, as these can support S-parameter data input. Arpad responded that this may not be a strongly desirable option. Bob added that the team should watch out for other SPICE variants which may not support .DATA, etc. if it ends up in IBIS-ISS. Arpad suggested it could be added later. Michael noted that the .LIB/.ENDLIB pair was implied present in earlier ISS drafts, but could cause hierarchy issues if it remains. Arpad noted that .LIB is highly similar to the .INC statement, but with delete capability; ISS therefore, does not need it. Bob suggested that it could be used as a way to support bringing in/deleting ISS subcircuits. Arpad responded that there was no need to include subcircuits with .LIB, so not .LIB would not be needed at the top level. Arpad noted that .LOAD/.SAVE is more of a simulator command, so should remain prohibited. Similarly, .IF/.ENDIF can be tabled for later, as it is both tricky to use and may not be widely supported. The team began reviewing Bob's list of comments on the ISS document, but ran out of time. On p. 12, IBIS-ISS does not support all the functions listed. Several elements aren't shown here, such as the B-element or I-element. Also, V-element prohibitions such as POLY are not mentioned. Michael responded that this was true but that the list was not meant to imply what is named is also allowed. Instead, the list was intended to help avoid ISS collision with other SPICE variants as there's an implied context for each word; would it help to just list out the words one shouldn't use? Bob suggested the language: "This list includes reserved operator [names] that are not part of ISS but may be part of other variants" Walter added that the P-element (port element) should be prohibited as a simulator directive, as it is chiefly used to extract S-parameters, a function which IBIS-ISS will not support. The remainder of Bob’s comments plus Arpad’s comments will be addressed in the next ISS discussion.